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ABSTRACT 



This analysis examines the sealift execution scheduling process with the purpose of 
identifying factors which require consideration in the development of an automated 
execution scheduling system. Organizational, communicational, and algorithmic factors 
are examined and assessed as to importance in scheduler development. From this 
assessment, a proposed system structure is developed to provide a high level framework 
upon which further research and development can be built. Recommendations for interim 
improvement in the process are made as well. 
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I. PROBLEM INTRODUCTION 



A. BACKGROUND 

Strategic sealift is a major factor in the response and mobilization capability of this 
nation’s armed forces. In a major operation, sealift will account for 90-95% of cargo 
movement [Ref. l:p. 4-1]. Recognizing the importance of such a capability, the 
Secretary of the Navy has designated strategic sealift as a primary mission area. The 
command responsible for directing and managing the successful accomplishment of the 
strategic sealift mission is the Military Sealift Command (MSC). MSC’s responsibilities 
include both deliberate planning and execution aspects of strategic sealift employment. 
Also tasked with ensuring the effective use of sealift and all transportation resources is 
the United States Transportation Command (USTRANSCOM). Established in 1987 as 
suggested by the Department of Defense Reorganization Act of 1986 (commonly referred 
to as the Goldwater-Nichols Act), USTRANSCOM is a joint, specified command 
responsible for transportation missions, responsibilities, and the forces of the three 
Transportation Operating Agencies (TOAs), Military Traffic Management Command 
(MTMC), Military Airlift Command (MAC), and MSC. In a peacetime environment, 
USTRANSCOM centers its efforts upon developing and evaluating wartime planning and 
execution procedures. It does not direct the administration of routine peacetime military 
transportation. However, in a deployment/execution environment, USTRANSCOM 
assumes operational command of all three TOAs and directs the employment of all 
strategic transportation resources. So, in an execution scenario, MSC schedules sealift 
under the control of USTRANSCOM. 
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B. SEALIFT CHARACTERISTICS 



Sealift is, by structure and nature, a difficult process to manage. There is no large 
dedicated sealift force available in place as there is with airlift. Therefore, the 
composition of the sealift base that MSC will have to draw on is determined primarily by 
private sector economic factors. Such factors include labor, construction, and operating 
costs as well as commercial usefulness and taxes. As a result of these factors, sealift 
ships tend to vary a great deal in such characteristics as speed, range, capacity, mission, 
and military usefulness. These economic factors have also reduced the size of the U.S. 
commercial fleet with large portions of the world commercial fleet sailing under foreign 
flags of convenience. The net effect of the military usefulness and flag of convenience 
factors is to put sealift schedulers in the position of having to manage an extremely scarce 
resource. Also impacting this scarcity are the speed and range factors. At best, a given 
ship can make an Atlantic transit to Europe in seven to ten days. The transit times are 
much greater for Pacific transits. This reduces the availability of ships for multiple lifts, 
especially if a ship is on the low end of the speed range. These considerations all 
culminate in the determination that sealift execution scheduling must be done intelligently 
and efficiently to derive the maximum benefit from scarce resources. 

C. DEVELOPMENTAL PRIORITIES 

While great attention and resources have been applied to deliberate planning 
processes and systems, little effort has been applied to execution scheduling. Deliberate 
planning centers around developing a concept of operations for an operation plan 
(OPLAN) and validating the requirements and feasibility of that plan. Conceivably, the 
information developed for that OPLAN could be drawn upon in an actual crisis, and, with 
appropriate modification, be used for execution. The problem is that while deliberate 
planning systems have been develop>ed and improved, little effort has been devoted to 
developing and improving the execution scheduling systems necessary to realize the 
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objectives of those OPLANs. Execution scheduling is still largely a tedious, manual 
process, completely different from the deliberate planning process. If the deliberate 
planning process is to have any real value, an equally effective execution scheduling 
process must be established. 

D. PURPOSE AND METHODOLOGY 

The purpose of this analysis is to examine and define the sealift execution 
scheduling problem in order to provide a framework upon which an effective scheduling 
system can be developed. The factors to be examined include the actual execution 
process, existing systems, interfaces, and system requirements. From this examination, 
a broad, high level system structure will be proposed. This structure will not be 
sufficient in detail to begin system development. It will be sufficient to direct further 
research into subareas of the execution scheduling problem. The hope is that such 
research will eventually culminate in an effective, automated scheduling system. 
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U. EXECUTION PROCESS DESCRIPTION 



A sealift operation is a massive undertaking. Even so, it is but a subfunction of an 
entire process known as the Crisis Action System (CAS). This system is implemented in 
crisis situations where time constraints are of great significance [Ref. 2:p. 209]. These 
situations are further delineated as follows: 

• Time available to plan the operation is limited to only a few days or weeks; 

• Timely identification of resources is necessary to prepare forces, transportation, 
and supplies; 

• Actual movement and employment of forces is expected in the immediate future. 

The purpose of CAS is to enable the Joint Deployment Community (JDC) to plan, 
deploy, and employ U. S. military forces in an organized and expedient manner in a 
relatively short period of time. These procedures are keyed upon effective use of 
whatever time is available, rapid and effective communications, and use of previous 
planning wherever possible. CAS is composed of the six following phases: 

I. Situation Development 

II. Crisis Assessment 

III. Course of Action Development 

IV. Course of Action Selection 

V. Execution Planning 

VI. Execution 

All participants in the process have specific responsibilities and goals for each 
phase. However, it should be noted that in a time-sensitive situation, significant 



4 



compression of the above phases can be directed. In such a situation a move directly 
from Phase I to Phase V is well within the realm of possibilities. 

CAS participants include the National Command Authorities (NCA), Joint Chiefs 
of Staff (JCS), supported command (usually the Unified Commander responsible for 
execution or plan development), supporting commands (commands who provide 
augmentation forces or other support to the supported command), military services, 
USTRANSCOM, and the TOAs. The primary means of interface and communications 
for CAS is the Joint Deployment System (JDS) and the World-Wide Military Command 
and Control System (WWMCCS). While CAS covers the entire deployment effort, only 
those functions germane to the sealift execution problem will be discussed here. 

A. CAS PHASES I AND H - SITUATION DEVELOPMENT AND CRISIS 

ASSESSMENT 



CAS Phases I and II are essentially crisis identification and monitoring phases. JCS 
activates the CAS when it determines that a given situation has the potential to escalate 
into a crisis. JCS may at this juncture direct all participants to join a JDS on-line crisis 
teleconference through WWMCCS [Ref. 3:p. 1-2-1]. 

B. CAS PHASE m - COURSE OF ACTION DEVELOPMENT 



Phase II terminates and Phase III commences with the issuance of the Warning 
Order from JCS [Ref. 3:p. 1-2-2]. The Warning Order contains the following elements: 



• Situation 

• Specific forces to include identification of supported and supporting commands 

• Mission 

• Potential Courses of Action (COA) 

• Designation of potential commencement of deployment and employment dates 
(C-Day and D-Day) 

• Initial allocation of lift resources for planning 

• Other information required for execution planning 
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The responsibility of the supported command during this phase is to further develop 
the potential COAs. This can be accomplished in one of several ways. The preferred 
method is to utilize an OPLAN already generated for JDS. This OPLAN will be a 
product of the deliberate planning process and will require some revision to meet the 
specific requirements of the crisis response. For those situations where no OPLAN is 
available, a COA can be developed on-line with JDS or off-line locally for later input to 
JDS. The latter method has the disadvantage of not allowing the supporting commands 
to participate on-line in the development process, possibly requiring further revisions after 
the other participants are able to review the COA. 

Once development of a particular COA is complete, USTRANSCOM is notified by 
the supported command that the COA is available for a deployment estimate. The next 
step is to determine a closure estimate. A closure estimate is a projected date of 
completion for the deployment, expressed relative to C-Day. With the TOAs, 
USTRANSCOM provides closure estimates for each mode of transportation. At the 
same time USTRANSCOM and the TOAs are at work on these estimates, the supporting 
command and the services are analyzing the COA to determine the feasiblilty and 
supportablilty issues critical to the operation. Depending on time-constraints, this can be 
an iterative process, requiring the supported command to make changes to the COA based 
on responses from USTRANSCOM, supporting command, and services. 

The end product of the phase is the Commander’s Estimate (OPREP-1). This 
message is generated by the supported command after the deployment estimates are 
received from USTRANSCOM [Ref. 3:p. 1-3-9]. The Commander’s Estimate is 
forwarded to JCS along with a recommended COA for decision. 
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C. CAS PHASE IV - COURSE OF ACTION SELECTION 



Phase IV essentially consists of a decision stage. At this point, the National 
Command Authority (NCA) has the Commander’s Estimate and is considering the COAs 
that have been developed for the crisis. Meanwhile, JCS has the option of issuing a 
Planning Order to the participants. The main purpose of this order is to speed up 
execution planning by providing specific guidance for actions to be taken in advance of 
the NCA decision. Expending on the situation, the Planning Order may be the first 
official guidance provided to some of the participants or it may be an update of previous 
guidance. The Planning Order will normally contain the following elements: 

• Forces and resources to be used in planning 

• Objectives, tasks, and constraints of the operation 

• Further planning guidance as appropriate 

• Deadline for operation order 

The participants will begin planning in accordance with the direction of the 
Planning Order. [Ref. 2:p. 229] 

D. CAS PHASE V - EXECUTION PLANNING 

This crucial phase begins with the issue of the Alert Order from JCS indicating the 
COA selected by the NCA and tentative or actual target dates for the operation. Based 
on the information in the Alert Order, the supported command converts the COA into the 
operation order (OPORD). The successful completion of this phase is critically 
dependent upon USTRANSCOM and JDS. USTRANSCOM is the central coordinator 
for execution planning and JDS is the primary instrument of that planning and 
coordination. The central object of planning is the first increment of deployment, relative 
to the Earliest Arrival Date (EAD) and C-Day (COOO), For sealift, the first increment 
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is 30 days of scheduled lift from COOO - C029. For airlift, the first increment is 7 days 
of scheduled lift from COOO - C006. [Ref. 3:pp. 1-9-5 - 1-9-8] 

Initially, USTRANSCOM releases JDS coordinating instructions to all participants. 
Included in these instructions are target dates for completion of updates to the JDS data 
base. For the supported command, these updates are generated adjusting the requirements 
of the COA to correspond to the Alert Order. The supported command is also required 
to validate and update the data base for the first increment. When USTRANSCOM 
receives notification of validation completion, the supporting command is notified to 
begin sourcing the increment. Sourcing is a procedure by which the supporting command 
resolves actual units, origins, and other characteristics against the hypothetical force 
requirements contained in the Time-Phased Force Deployment Data (TPFDD) file [Ref. 
2:p. 335]. Accurate sourcing is critical to successful movement. If unexpected or non- 
standard units or unit equipment are to be moved, it may unnecessarily delay items 
crucial to the success of the operation. The supporting command is also responsible for 
scheduling and manifesting organic transportation. Organic transportation is defined as 
transportation resources assigned to a unit that can provide lift capability for part or all 
of the unit’s movement requirements, requiring partial or no support from the TOAs 
[Ref. 4:p. 5-24]. 

USTRANSCOM will perform data validation upon the data base once it is notified 
by the supporting command that sourcing and updating is complete. Once this data 
validation procedure is complete, the data base is released to the TOAs for scheduling. 
The TOAs will schedule lift for the first increment and any preparatory moves called for 
in the OPORD. Entry of airlift schedules is exp>ected within 12-36 hours from release 
and sealift schedules within 24-48 hours. After the schedules are entered and 
USTRANSCOM is notified, no changes are allowed to the data base unless coordinated 
through USTRANSCOM. 

USTRANSCOM is also tasked with monitoring any preparatory moves as scheduled 
above. These moves are normally reflected as N-Day requirements in the data base, 
where N is the number of days before C-Day [Ref. 3:p. 1-9-10]. For example, N002 
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would be two days prior to C-Day. Once a preparatory move is completed, either the 
supporting command or the parent service is tasked with updating the data base to reflect 
the new geographic location of that unit. No further moves are made until the execution 
order is given to begin Phase VI. 

E. CAS PHASE VI - EXECUTION 

The execution phase begins with the issue of the execution order from the NCA via 
JCS. When the order is received, the date and time for execution is reviewed to 
determine if any adjustment is required to the first increment. If significant adjustments 
are required, the TOAs may elect to recompute the entire schedule, a process known as 
reflowing the increment. If only minor changes are required, then the changes are made 
and execution begins as scheduled [Ref 3:p. 1-9-12]. USTRANSCOM will then begin 
transmission of Automated Scheduling Messages (ASMs) to the units or major commands 
involved. The TOAs continue incremental scheduling, adding a day or more of 
scheduling information to JDS with each iteration. They also maintain the actual status 
of units and lifts in JDS while USTRANSCOM assumes a monitoring and coordination 
role. The actions performed during this phase continue until the operation is complete. 

F. CAS TIMING FACTORS 

As has been stated before, the major thrust of CAS is expedient deployment of 
forces in a time-critical crisis. The possible compression of phases and limited time to 
plan places a severe strain on current sealift scheduling resources. A period of 24-48 
hours to schedule sealift for a major mobilization is a significant undertaking for a 
computerized scheduling system, let alone a manual one. Unfortunately, with the dearth 
of resources devoted to the execution scheduling problem, the latter approach is the one 
most often used. The following chapter will describe the systems that are currently 
available and their shortfalls with respect to the execution scheduling problem. 
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m. EXISTING SYSTEMS 



There are two primary deficiencies in existing systems that preclude acceptable 
performance in sealift execution scheduling. The first deficiency is one of purpose. 
Much of the software that has been developed to date has been established to validate 
operational plans. They do well at evaluating feasibility, but fall short in terms of 
efficient scheduling. The Strategic Sealift Contingency Planning System (SEACOP) can 
take up to 18 hours to evaluate a plan. The other problem is a consequence of the size 
of the deployment database involved in executing a plan. In order to manage the vast 
amounts of data associated with this process, the data base management system approach 
has been embraced. The Joint Deployment System (JDS) and the Command and Control 
Center Prototype, explained below, are both examples of this approach. Unfortunately, 
the computational overhead associated with a data base system is too severe both in 
memory usage and CPU time to be effective in a scheduling role. 

A. JOINT DEPLOYMENT SYSTEM 
1. Background 

The Joint Deployment System is defined by AFSC-1 [Ref. 2:p. 319] as: 

Personnel, procedures, directives, communications systems, and electronic data 
processing systems that directly support time-sensitive planning and execution and 
complement peacetime deliberate planning by disseminating deployment 
information. 

The electronic data processing system portion of JDS is an extensive information storage 
and retrieval system with a graphical display system to allow geographic displays of the 
deployment objectives and process. It is the sole source of deployment information for 
the TOAs and is controlled by USTRANSCOM. JDS does not perform scheduling; rather 
it is the input and output point for the scheduling packages of the TOAs. The information 
that JDS provides is the applicable portions of a plan’s TPFDD. These data encompass 
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all of the movement and cargo re<quirements, prioritization of arrivals, and other data for 
a given plan. [Ref. 2:p. 337] 

2. Interfaces/Users 

The TO As access JDS through WMMCCS. In the case of MSC however, its 
JDS support comes through the OPNAV WMMCCS site located at the Pentagon. MSC 
and the area commands, MSCLANT and MSCPAC, have on-line access to JDS, but they 
are not supported as JDS end-users by the JDS support organization. Information can be 
retrieved in the form of printed reports or on magnetic media. It can be retrieved in 
pre-specified formats, or specialized retrievals can be developed to extract required 
information using a retrieval language similar in syntax and format to COBOL. 

Returning processed schedules to JDS is not quite as simple. The WMMCCS 
Intercomputer Network (WIN) sites at MSC and the area commands are secure areas with 
tightly controlled access, due to the nature of the information available. One of the 
restrictions placed upon such sites is that magnetic media may only be brought into the 
site with absolutely no information contained upon it. This precludes any automated 
input of scheduling information developed outside of the WIN site. At present no means 
exist to develop that information within the site. Therefore, any scheduling information 
developed by an MSC Area Command must be entered into JDS manually by WIN 
personnel. 

3. Limitations 

Interface with JDS is necessary for any sealift scheduling system, be that 
interface direct or indirect. Using JDS’s retrieval language to do the scheduling is not a 
viable option, though properly structured and supported retrievals could be of immense 
help in reducing the workload for a scheduling system. Proper support would include 
assistance in developing those retrievals from the JDS support organization at 
USTRANSCOM and in rewriting those retrievals when changes are made to the JDS 
database structure. 



11 



The performance of any scheduling system will also be degraded by any 
manual transfer of information. A system which develops a schedule in 12 hours, but 
takes another 12 hours for the schedule data to be entered manually is not responsive to 
a crisis. Some means of on-line or automated communication with JDS must be 
established. This can be accomplished by incorporating the system in the WIN site or by 
modifying the entry restrictions to allow magnetic media containing the schedule to enter 
the site. One possible solution would be to use some type of encoding which would allow 
a WIN operator to determine if the information has been corrupted or tampered with. 
The security of the site should not be compromised, but some means must be found of 
transferring the schedule electronically at the area command level. 

B. STRATEGIC SEALIFT CONTINGENCY PLANNING SYSTEM 
1. Background 

SEACOP is a system initially developed in 1972 as a transportation planning 
model sponsored by the Strategic Sealift Division of CNO (OP-42) [Ref. 5:pp. iv, 1-3]. 
It is operated by MSC and is used to generate schedules based on a plan, exercise, or 
study. It is in its fourth development iteration and resides on a WMMCCS Honeywell 
6(XX) at the Washington Navy Yard. It is essentially a single plan gross scheduler which 
uses a heuristic process to schedule plan lift requirements against lift assets, port 
constraints, and time requirements. It produces several feasible schedules from which a 
"best” schedule may be selected. It is a deliberate planning tool that is often used for 
actual scheduling given the fact that nothing else exists for that purpose. It can take up 
to 18 hours to run, depending on the size of the plan. It is constrained to a single reel 
of tape for input, which requires extraction of the sealift requirements from the TPFDD 
for a large plan [Ref. 5:p. 1-19]. 
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2. Interfaces/Users 

SEACOP receives the TPFDD and movement table by tape downloaded from 
JDS and MTMC through the MSC WIN site. Ship information and allocations are 
obtained from the Joint Strategic Capabilities Plan (JSCP) Annex J and, where necessary, 
on tape from the Navy Operational Intelligence Center. It uses several internal files 
including a port characteristics file and a type unit characteristics (TUCHA) file 
containing detailed cargo data and quantities for standard military units [Ref. 5:pp. 1-13 - 
1-14]. The output consists of selected reports and an MSC movement records file which 
is transferred via WIN to USTRANSCOM/JDS. Additional information extracted from 
the schedule is made available to MTMC and the MSC area commands through the WIN 
site. 

MSC is the sole user of SEACOP. Planners who wish to validate a plan must 
submit the tape to MSC and request MSC conduct the SEACOP analysis. MSC area 
commands have no capability to use SEACOP, even though the movement requirements 
that they extract from JDS are generated by SEACOP. 

3. Limitations 

SEACOP is a deliberate planning tool inappropriate for execution scheduling. 
It has no capability to reanalyze or readjust a schedule. Its heuristic processes are slow 
and do not necessarily produce an optimal schedule. It has been modified extensively and 
lacks potential for any improvement. Unfortunately, until something better can be 
developed, it is the only sealift scheduling tool available. This is also unfortunate for the 
area commands in that they still have no definitive software scheduling aid, and in a 
deployment, exercise or actual, most of the scheduling will fall upon them. 
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C. SEASTRAT/SAIL 



1. Background 

The Sealift Strategic Analysis System (SEASTRAT) is the new deliberate 
planning tool for sealift scheduling under development by the Navy Regional Data 
Automation Center (NARDAC) in Washington, D.C. [Ref. 6:pp. xi, 3]. SAIL, the 
Scheduling Algorithm For Improving Lift is being developed as a subsystem by the 
Computing and Telecommunications Division at the Oak Ridge National Laboratory 
(ORNL). It is being implemented on a new IBM 3090 mainframe computer at MSC by 
NARDAC and ORNL. SAIL uses a combination of linear optimization and heuristic 
techniques to develop schedules for planning and validation purposes. It is written in 
FORTRAN 77 and interfaces to SEASTRAT and the required files through the mainframe 
database system, FOCUS. It is still in development and testing, and as its developers 
indicate, is subject to "...changes in the overall planning process within the deployment 
community." [Ref. 6:p. 5] SAIL uses specific aggregation techniques to reduce the 
number of cargos for scheduling by combining cargos into a "channel". This "channel" 
consists of a group of cargos with similar characteristics and delivery constraints. This 
allows the lift process to be modelled as a continuous flow, a necessary condition for a 
linear programming formulation. SAIL also uses simulation routines to derive port 
queueing and loading times to give a more realistic appraisal of plan feasibility. 

2. Interfaces/Users 

The inputs and outputs of this system are not unlike those of SEACOP. One 
difference is the use of FOCUS by SEASTRAT to manage the information files used by 
SAIL. Although this provides a means of easing the data management effort, it has a 
negative effect upon system execution time due to the computational overhead inherent 
in using FOCUS. The output side is similar in that it has to be able to communicate with 
JDS. 
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3. Limitations 

The developers of SAIL stipulate from the beginning that it is a deliberate 
planning tool not intended for execution scheduling. Even with its aggregation 
techniques, the structure of an actual execution problem may still be difficult for a linear 
programming transportation formulation. One consequence of the channelization 
approach is that once cargoes are aggregated into a channel they lose their individual 
identities. This is not acceptable for an execution scheduling system which must allow 
for retrieval of a cargo’s status at any given time in the deployment process. A more 
discrete approach may preclude a linear programming approach. SEASTRAT’s use of 
FOCUS as the database interface causes severe difficulties for the system in terms of 
package execution time. However, the system’s purpose for existence is plan validation. 
It appears to be a reasonable and intelligent attempt to address the lift scheduling 
problem. Since it is a deliberate planning tool, it is not designed to be able to address the 
unique requirements of an execution scheduling system. This does not exclude the 
possibility that an execution scheduling system might be able to draw upon those elements 
in SEASTRAT/SAIL that would be appropriate for the execution scheduling problem. 

D. COMMAND AND CONTROL CENTER PROTOTYPE 
1. Background 

The Command and Control Center (CCC) Prototype is a PC based information 
system implemented on a TEMPEST-certified, secure Zenith AT-Compatible with two 
removable ten megabyte hard drives. It is a combination of AUTOCAD for graphical 
displays, Paradox for the database. Software Carousel to allow for swapping between the 
two, and a driver program written in C. The database retrieval routines are written in a 
Paradox-specific retrieval language and compiled so as to be inaccessible to the users. 
It was developed under MSC contract and was put into operational testing at MSC 
Headquarters and the area commands in the fall of 1988. At that time, the system was 
only capable of using movement rep>orts to track the location of ships. The users at the 
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area commands were under the impression that the system in a later iteration would be 
capable of serving in a scheduling role. 

2. Interfaces/Users 

At the time of its operational test, the CCC prototype had no means of 
automated input. Entering movement report data was completely dependent upon 
keyboard entry. It had no capability to extract information on-line, though it was thought 
that database files might be transferred from the CCC prototype at MSC headquarters to 
the area commands via the secure data transfer mode of the STU-III Secure Telephone 
System. This would still mean that the information would have to be entered manually 
at some point, be it at headquarters or the area commands. 

There were only two means available of retrieving information from the 
prototype. The first was through printed reports and the other would be through the 
displays generated by AUTOCAD. Unfortunately, the secure Zeniths are equipped with 
only a Color Graphics Adapter and Display. The information displayed by AUTOCAD 
at that resolution was so cluttered as to be of limited value. 

3. Limitations 

The CCC prototype is an example of an ill-conceived and poorly executed 
software procurement. It performs only nominally in its information retrieval role and 
is so constrained by all aspects of the Zeniths as to restrict the potential for enhancing or 
expanding the system. In terms of disk space, it uses most of the storage available on 
each of the ten megabyte drives. With both AUTOCAD, Paradox, and Software 
Carousel it consumes virtually all of the Zenith’s main memory and a two megabyte 
extended memory card, leaving little room to operate on new data. The loading and 
execution of the package is painfully slow. The system requires that AUTOCAD be 
loaded, executed in full, and swapped out before Paradox can be loaded and run. This 
entire process takes about ten minutes before any data entry or retrieval can be 
performed. Initial indications were that the removable drives, known for their slow 
throughput, were the reason for the slowness of this process. An interleave adjustment 
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was performed, increasing the access speed of the disks by 50% according to recognized 
benchmarks. When the system was loaded from those disks, there was no appreciable 
decrease in the loading time, indicating that the process was CPU intensive, not disk 
intensive. 

The contractor has addressed some of these concerns and stipulates that most 
of the problems will be solved if the system is implemented on an 80386 based PC. 
Unfortunately, at the time of this writing there are no TEMPEST-certified 80386 
machines available, so use of a non-TEMPEST machine, while still being able to 
minimize the TEMPEST hazard, is being investigated. Such a system would probably 
make the information retrieval and display less painful, but is still not likely to allow for 
the expansion of the package in terms of scheduling. And the communications/data 
transfer aspects remain unaddressed. 

E. OTHER SYSTEMS 

Many other avenues have been explored on an in-house level to assist in sealift 
scheduling. One example is a program of approximately 2500 lines of BASIC code to 
sort the movement data downloaded from the WIN. This program sorts the data by 
POE, POD, and ALD, extracts the valid unscheduled cargo, and provides a gross 
assessment of how many of each possible type of lift asset would be necessary to move 
the unscheduled requirements. Unfortunately this program is strictly dependent upon the 
format of the retrievals from JDS. Given the fact that the area commands are not 
supported JDS users, they have no control over those retrievals. And those retrievals 
could easily be rendered useless by changes to the JDS database. Any system to perform 
sealift execution scheduling must be isolated from such changes. 
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IV. SYSTEM REQUIREMENTS 



A. LEVEL OF SYSTEM OPERATION 

One of the critical factors in an execution scheduling system must be a clear 
specification of the level at which each of the potential users/user organizations may 
exercise control over its operation. Those users, whose need for the system is strictly 
informational do not need the same access to the system that a person with scheduling 
authority needs. Therefore, a distributed approach to sealift scheduling is in order for the 
execution problem. 

1. USTRANSCOM 

USTRANSCOM would, at most, need informational access to the system. If 
the system were properly configured to interface with JDS, USTRANSCOM would likely 
satisfy its informational requirements from JDS and not even bother with access to the 
system. 

2. MSC Headquarters 

Owing to the fact that execution scheduling in the past has been dependent 
upon the deliberate planning tools available at MSC Headquarters, MSC has been heavily 
involved in the initial stages of the actual scheduling process. Their ability to participate 
beyond the first increment is limited by SEACOP’s restriction to a single schedule. But 
under ideal circumstances MSC should occupy a role similar to USTRANSCOM. It 
should monitor the scheduling process, allowing the personnel at the area commands with 
the first-hand knowledge critical to effective scheduling to perform the actual scheduling 
tasks. This monitoring could possibly be accomplished through JDS as well. If a 
determination is made that MSC Headquarters should have a participatory role, that 
participation should be limited to the first increment. 
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3. MSC Area Commands 

The two MSC area commands that will be crucial to mobilization planning and 
execution are MSCLANT and MSCPAC. Responsibility for ensuring the timely 
scheduling of lift rests squarely within those two commands. They are, in fact, the 
operational commands of MSC. The local knowledge of facilities, characteristics, and 
quirks of the their transportation environments is critical to effective scheduling. Yet, 
these areas have been the most ignored in terms of automated scheduling support. Any 
given OPLAN can require the scheduling and coordination of thousands of items, all with 
several specific time and loading constraints. This is currently accomplished with pencil 
and paper. MSCLANT and MSCPAC are where the emphasis on sealift execution 
scheduling should be placed. Any tools developed for their use should be closely 
coordinated with their scheduling personnel, not just their procurement or ADP personnel. 
This was not what was done with the CCC Prototype and the result will likely be the 
death of that package. It is a well known fact in software development that proper 
requirements definition will make or break a package. This package should be designed 
specifically for the use of the area commands in the context of their facilities and 
requirements, preferably through contact with personnel at the area commands. 

B. OPTIMALITY/PERFORMANCE CRITERIA 

The most significant parameter in the whole arena of sealift execution is time. In 
a crisis situation, the search for the optimal schedule becomes secondary to the availability 
of scheduling time. Such a search can involve evaluation of several deployment and 
schedule options. Therefore, the developer must define speed of package execution as 
the objective function, with schedule feasibility /optimality as a constraint. This is not to 
suggest that optimality be ignored. In an era of scarce sealift resources, inefficient use 
of assets could be deadly. But instead of an exhaustive search for the optimal schedule, 
the emphasis should be placed on developing a "good" schedule that observes the 
feasibility constraints placed upon it. This may, in fact, require more human interaction 
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or heuristics to identify a "good" schedule than would be normally present in a pure 
optimization/scheduling package, but this is not a typical scheduling problem. SEACOP 
is widely recognized as a bad approach to the problem, consuming large computing 
resources and time without rendering any flexibility to evaluate alternative lift options. 

C. SOFTWARE DEVELOPMENT CONSIDERATIONS 

As documented previously, attempts to manage the execution scheduling problem 
with existing systems or database management systems (DBMS) have met with little or 
no success. This is because the execution scheduling problem is totally different from the 
problems that the other systems were developed to handle. Execution scheduling is at its 
core a complex optimization problem and only an effort by optimization professionals will 
yield a package capable of meeting the challenge. 

An execution scheduler need not exist external to a deliberate planning package. 
If all of the interfaces and information required for the execution scheduling package are 
contained within the deliberate planning package, then the scheduler could exist as an 
independent module included within. Unfortunately, even SEASTRAT does not meet this 
requirement. The IBM 3090 mainframe on which it is being implemented is not 
accessible to the area commands, violating a major requirement for an effective system. 
Therefore, either some means of access to the 3090 for the area commands will need to 
be developed or the execution scheduling package will have to be developed 
independently. 

Another approach to avoid in scheduler development is the DBMS approach. This 
approach can be manifested either by developing the scheduler in a DBMS retrieval 
language or by tying it to a DBMS for its input and output. The problem with the first 
method is that a DBMS retrieval language is not suited for the significantly complex and 
time-critical computations inherent in an optimization problem. It is akin to trying to 
write a supercomputer operating system in BASIC. It can be done, but it would make 
little sense to do so. The problem with the second method is time. Input/output 
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processes are slow enough without compounding the situation with calls to a DBMS. 
However, it is recognized that the amount of data used by a scheduler would be extremely 
large and difficult to compile and maintain without a DBMS. The key here is to structure 
the scheduler to take input from a flat or text file format containing only that information 
required for scheduling. This flat file format could be produced by the DBMS following 
an update so that it would be available to the scheduler. This way the scheduler could 
input the information much faster than it would by making calls to the DBMS for each 
item required. 

Another popular trend in software development is to utilize off-the-shelf software 
to drive down procurement costs, especially for Personal Computer (PC) software. This 
may be appropriate for a DBMS or word processor, but it is entirely unsuitable for 
scheduling purposes. The CCC Prototype is an excellent example of that fact. Even 
most of the popular optimization packages available today would be unable to deal with 
the requirements of this system without substantial modification. It should also be 
mentioned that while keeping a package small and portable enough to run on a PC is an 
admirable goal, the sheer volume of information, mass storage, memory, and speed 
demanded of a such system will require mainframe computing power. 

D. USER INTERFACE 

The user interface is a critical area for two reasons. One reason is that the time it 
takes the users to operate the system can be pivotal in terms of quickly executing lift 
options. If a reflow of a COA is required or the next schedule increment is required, the 
time required to use the scheduler can slow up the process significantly, especially if the 
user is at a remote site and the communications link is operating below 9600 baud. The 
other reason lies in the fact that the scheduler will be ineffective as a "black-box" 
optimization package. It is the nature of military operations that changes and exceptions 
are often made. Sealift is not exempt from such changes. The Naval Control of Shipping 
Organization (NCSORG) is a prime source of possible changes [Ref 7]. It will have the 
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authority, when established, to control ports, schedules, and convoys, all of which will 
have a significant effect on scheduling procedures. Some override capability must be 
designed into the system. Manual verification and approval procedures must be 
incorporated into the scheduler. This might appear difficult from the standpoint of a 
optimization package. However, Brown et al. [Ref. 8] developed such a system for 
Mobil Oil that has increased productivity and saved money. The task here is not 
insurmountable. 

E. EXTERNAL INTERFACES 

Again, speed and time are the critical factors. The scheduler must be in such a 
position as to effect a rapid exchange of information with JDS for both the initial and 
subsequent lift increments. Too many things depend upon that exchange. The entire JDC 
derives its execution schedules and plans from JDS. Manual entry of schedules through 
a WIN site following scheduling is not acceptable. The scheduler requires a direct 
interface with JDS, preferably at a speed of 9600 baud or greater. Even at that speed, 
a large schedule could take up to an hour to upload. One place where the transfer rate 
could be improved is the regional area. The CONUS MSC and MTMC Area Commands 
are located in close proximity to each other. Given the close nature of coordination 
required between MTMC and MSC locally, some sort of high speed, secure data link or 
even sharing of computing resources could significantly enhance that coordination. For 
example, if it were determined that MSC’s requirement for a mainframe computer in the 
area was not sufficiently justified, perhaps a mainframe computer for both MSC and 
MTMC together would be more easily supported, especially by USTRANSCOM. 

In terms of information flow, some work has been done previously to study 
requirements. The U.S. Department of Transportation prepared a report for JCS in 1986 
to determine possible interfaces for MTMC and MSC [Ref. 9]. The report is reasonably 
detailed in discussing JDC and MTMC systems, but unfortunately the preparers of the 
report were led to believe that SEASTRAT would be MSC’s execution scheduling system. 
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As of this writing, SEASTRAT is only a deliberate planning tool with no execution 
scheduler programmed in the immediate future. Still, the report can provide a starting 
point for establishing a more effective interface in the locality. 

Two other areas of interface to be addressed are the Maritime Administration 
(MarAd) and NCSORG. MarAd is responsible for supporting sealift through the Ready 
Reserve Fleet (RRF), National Defense Reserve Fleet (NDRF), the Voluntary Tanker 
Program, and Sealift Readiness Program. In its wartime capacity as the National 
Shipping Authority (NSA), MarAd is responsible for the requisitioning of U.S. flag 
merchants to provide additional lift in time of war [Ref. 10]. In time of mobilization, 
MarAd would be the primary source of lift assets for the initial surge. The only 
automated interface between MSC and MarAd is a secure teletype link referenced in the 
Department of Defense and Department of Commerce memorandum of agreement that 
addresses shipping support of military operations [Ref. ll:p. 17]. This is presumably 
where MarAd will identify assets to be made available for lift and MSC will identify 
requirements. Such a link would be probably sufficient for those purposes, but, if 
MarAd, in its wartime capacity as the NSA, had a greater requirement for information, 
that link would have to be reevaluated. 

The NCSORG question is somewhat more difficult. The easiest and most desirable 
solution would be to maintain scheduling authority with MSC and have the NCSORG 
direct schedule changes as necessary. Some provision would have to be made to allow 
informational access to either the scheduler or JDS for the NCSORG. The difficulty lies 
in determining at which point in the scheduling process NCSORG would exercise its 
scheduling prerogative. While this would probably not come into question for a non- 
wartime mobilization or in the initial stages of the deployment, it is a factor which could 
have a significant effect upon scheduling and should be given due consideration during 
development. 
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V. ALGORITHMIC CONSIDERATIONS 



The selection of a scheduling algorithm for an execution scheduling system impacts 
all aspects of system structure. This is a topic which requires much more research before 
the design of such a system can be implemented. While it is beyond the scope of this 
thesis to actually develop the algorithm required, an examination of the potential areas for 
algorithm selection and related impacts is in order. 

A. MATHEMATICAL PROGRAMMING 

The first area of consideration is a mathematical programming approach to the 
scheduling problem. This consists of linear and integer programming techniques. This 
has been the approach most frequently used in the past for some of the deliberate planning 
tools available today. Because a linear programming problem formulation requires a 
continuous vice discrete flow structure, development to date has centered around using 
channelization as a method of aggregating cargo requirements to reduce the problem size 
and meet the continuous flow assumption. Channelization gives the formulation a 
structure similar to a pipeline flow problem. For example, under channelization, a 
10,000 MTon cargo moving from POE to POD in 10 days would not be modelled as 
such. It would be modelled as 1000 MTons flowing per day over 10 days. This structure 
was the one for a deliberate planning package developed for USTRANSCOM called 
SCOPE-GT [Ref. 12;p. 21]. It is also the approach used in SAIL with some modification 
[Ref. 6:p. 19]. 

There are some problems with this approach, especially for execution scheduling. 
The most significant deficiency is one of cargo tracking and identification. If cargoes are 
aggregated into a channel as a continuous flow, it becomes impossible within the structure 
of the linear program and solution to identify individual cargoes and ships. SAIL 
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improves upon this somewhat by aggregating cargoes into a channel by unit loads and 
trying to schedule a channel to a single ship. However, there are no guarantees that this 
in fact will be the result. [Ref. 6:p. 29] The consequence of not aggregating cargoes 
increases the size of the linear program, rendering it potentially insoluble. Yet, the 
ability to track the movement of cargoes in a discrete fashion is a necessary requirement 
for an execution scheduling system. Two previous Naval Postgraduate School thesis 
students, Collier [Ref. 12] and Tally [Ref. 13], examined this deficiency in the context 
of deliberate planning systems and offered integer programming and variable reduction 
techniques in linear programming as potential means for structuring deliberate planning 
problems. Integer programming formulations meet the requirements for a discrete 
solution, but are typically more intensive computationally. Variable reduction techniques 
are used to reduce the size of a linear programming formulation. With the channelization 
approach as implemented in SAIL, these techniques all appear to be effective for lift 
scheduling in the deliberate planning process. Unfortunately, they do not appear to be 
the appropriate strategy for execution scheduling. 

Another factor which weighs against the use of these methods in execution 
scheduling is the dynamic nature of execution scheduling. A linear program or an integer 
program cannot be easily structured to handle the increasing time window of incremental 
scheduling. These mathematical programming techniques, by structure, require a 
complete problem for solution. If all of the lift assets, cargoes, times, and other critical 
constraints are known in advance for the entire execution, then such a formulation might 
be attractive. Unfortunately, execution scheduling is done in a dynamic context with the 
scheduling horizon increasing incrementally. For example, a linear program is used to 
develop a schedule for days C000-C029. The increment is increased to extend through 
day C031. The linear program is then used to recompute the schedule. Because the 
linear program solves two different, complete problems, the first schedule will likely have 
little similarity to the second. This can be a problem if a number of cargoes are already 
waiting to load or are in transit and the second schedule mandates a move between ships. 
The method frequently used to alleviate this problem is to develop a penalty for removing 
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cargoes that have already been loaded. Unfortunately, such methods unacceptably 
increase the computational size of an already large problem. 

However, total exclusion of mathematical programming techniques in addressing 
execution scheduling is not necessarily desired. Such techniques may be appropriate for 
use in a subproblem within the scheduler. But, a pure mathematical programming 
solution for the entire scheduling problem will not be a viable approach in terms of 
structure or computation time. 

B. HEURISTIC ALGORITHMS 

Given the size of the execution scheduling problem, a heuristic approach appears 
to hold the most promise. Such approaches are characterized by algorithms that apply 
intelligent criteria to determine a solution to a particular problem from a large number of 
possible solutions. The solution may be approximate, or in the case of optimization 
problems, sub-optimal. Some examples of heuristic algorithms are Newton’s method for 
numerically approximating the value of an integral or Dijkstra’s algorithm for determining 
the shortest path through a network of nodes. Depending on the criteria, a heuristic 
algorithm can produce a solution very quickly or quite slowly. SEACOP’s solution 
algorithm is an example of a heuristic algorithm that performs its task quite slowly. It 
develops schedules using a cost/benefit analysis heuristic that is based on aggregating all 
of the problem constraints into a penalty cost form. Wasted space on a ship is an 
example of a constraint for which a penalty is assigned. After a schedule is developed, 
it is then examined for "goodness", and bad cargo assignments are unassigned according 
to the worst cost/benefit values. Those cargoes must then be rescheduled. This process 
is significantly slow and inefficient in structure. [Ref. 5:pp. 2-80 - 2-85] 

However, not all heuristic approaches are as bad as SEACOP’s. In fact, one 
solution methodology appears promising. Within the last several years, more attention 
has been given to a class of problems known as Vehicle Routing with Time Windows , 
[Ref. 14]. These essentially involve a network of origins, destinations, and, possibly. 
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intermediate stops for which vehicles must be assigned. For each arc in the network, a 
cost and time to travel are specified. For each node (stop), a time window giving the 
earliest arrival date and the latest arrival date is specified, a constraint structure quite 
similar to the execution scheduling problem. These problems, if small or moderate in 
size, are amenable to solution through mathematical programming techniques. But for 
the large problems, the methodology centers around a heuristic approach to determine a 
feasible routing solution. This solution might not be the optimal solution, but given the 
size of the problem and the difficulty involved in computing the optimal solution, a 
feasible schedule that is "good" is acceptable. One such heuristic is a generalized 
permanent labeling algorithm as applied to the time windows structure [Ref. 15]. This 
heuristic is essentially a shortest path algorithm modified to consider time windows. 
Another is the Advanced Dial-A-Ride with Time Windows heuristic algorithm [Ref. 16] 
which deals with pickup, delivery, and quality constraints in scheduling multiple vehicles. 
Requests for pickup are made dynamically, though well in advance of the pickup time. 
While neither of these algorithms completely address the execution scheduling problem, 
they contain a structure and methodology close enough to it to be worth much more 
investigation. 

C. SCHEDULBS’G DYNAMICS 

One reason the heuristic approaches as described above are intuitively appealing for 
the execution scheduling problem is that they are capable of addressing a dynamic 
scheduling process. This dynamic process is characterized by two factors. The first 
factor is the incremental approach to lift scheduling. In a situation where sealift execution 
scheduling is required, JDS procedures dictate that the initial schedule be developed for 
the first 30 days of deployment. Following the development of that increment, the 
scheduling horizon is increased in increments of at least one day of lift. The size of the 
increase is not otherwise specified. As examined above, a mathematical programming 
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approach cannot satisfactorily perform in such a situation. Yet, the heuristic approaches 
can be structured to handle the changing schedule size. 

The second factor is one of ship allocation uncertainty. At any point in the 
scheduling process, there may not be enough lift assets identified to schedule lift against. 
There are three possible methods of dealing with this uncertainty. The first is the one 
used by MSC with SEACOP. If lift assets are not known when SEACOP is run, 
intelligence estimates are obtained for ship locations. From those estimates, a guess is 
made as to which ships will be allocated for sealift. The schedule is then developed using 
those ships. The second method is to develop notional ships that are representative of the 
type of ships that would be allocated. The notional ships are then used for scheduling. 
The problem with these two approaches is that if the ships actually allocated are 
significantly different in characteristics from those used for scheduling, recomputation of 
the entire schedule is required. This is not an efficient way to schedule. The third and 
more reasonable method is to structure the scheduler to schedule ships dynamically as 
they are allocated for sealift. This requires some dynamic representation of the cargo to 
be scheduled to facilitate the assignment of ships as they are allocated. One favorable 
consequence of this approach is that no special effort is required to incorporate returning 
lift assets into the scheduling process. Once an asset is identified as returning, it can be 
scheduled against the unscheduled cargo given its projected return date. This structure 
would be amenable to the heuristic methods described previously, though further work 
is necessary, especially to determine the best algorithm to use, especially when multiple 
ships are allocated at the same time. 

D. RULES/CONSTRAINTS/PARAMETERS 

A discussion of algorithmic considerations would be incomplete without closer 
examination of the scheduling rules and constraints that will affect an execution 
scheduling system. Much of the information presented here is drawn from factors . 
incorporated in SEACOP and SEASTRAT [Refs. 5, 6]. While these packages are not 
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suited to the execution scheduling problem, their identification of lift scheduling 
constraints is reasonably complete. 

1. Cargo Related Constraints 

Cargo characteristics will have a tremendous effect upon the scheduling 
process. Cargo volume and weight characteristics are the most obvious, but many special 
characteristics exist for many different cargoes, including requirements for segregation, 
ammunition restrictions, containerization, and special handling equipment. [Ref. 4:pp. 
3-13 - 3-52]. Some unit loads require personnel in attendance. The assumption that 
berthing space is available for those personnel is not necessarily a reality. Loading 
sequences for specific priority cargoes may be specified to ensure proper offload at POD. 
Close examination of the TUCHA file and Cargo Category Codes will be required to 
determine the significance of any special requirements that will impact scheduling. 

2. Ship Characteristics 

Obviously, the characteristics of the lift assets available are critical to effective 
scheduling. The speed, volume, weight, draft, and length of a given ship are required 
to determine what cargoes can be carried and which ports a ship might operate in. 
Generalization by ship type is not appropriate since there is wide variation in those 
parameters even among ships of a single type. Another consideration is one of mission. 
A tanker would probably not be best utilized in carrying ammunition or trucks. A non- 
self sustaining container ship needs specific crane services that might not be available in 
smaller ports without a crane ship or some other special arrangement. Speed will be an 
area where the NCSORG will have an impact. The maximum speed of a given ship 
might not be an accurate scheduling parameter if that ship is assigned to a convoy with 
a lower speed. 



29 



3. Distance Considerations 

Computation of distances is, for the most part, not a terribly complex problem. 
Some provision does need to be made for distance computation as a function of canal 
status. If the Panama Canal is not available, the distance between the Gulf Coast and 
Hawaii or California becomes much greater. One aspect of this computation which bears 
scrutiny is distance generation versus distance lookup. SAIL and SEACOP both compute 
distances at run time. If this computation is slower than a table lookup function, then 
some consideration of precomputing distances and storing them for lookup might be in 
order, so long as means remain of computing distances not already in the table. Also 
included under distance considerations are intermediate stops for onload/offload enroute 
and NCSORG track routing. 

4. Port Considerations 

Port impacts upon the problem can be significant. Certain ports may have 
draft/length restrictions or may not have the special handling equipment required for 
certain cargoes. Throughput at a given port might be constrained. Unfortunately, port 
selection is not within the purview of the sealift scheduling process at this time. MTMC 
selects the POE for a load and MSC determines what ship should be assigned to that load. 
If POE selection becomes a sealift scheduling subproblem, then more latitude can be 
given to the initial movement of a load. But, for the time being, the execution scheduling 
system is only concerned with whether or not a certain ship can be serviced in a given 
port. 

5. Time Constraints 

The three TPFDD/JDS specified times drive the time windows and constraints 
for the execution scheduling problem. The ALD indicates the date that the cargo is 
available for loading, and the EAD and LAD define the time window at POD. Other 
times which have an effect on the ability to meet those times are ship loading times and 
arrival time of ships at the POE for loading. Again, the NCSORG can have an effect in 
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that convoying can severely constrain the system’s ability to schedule lift to arrive within 
the time window specified. 
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VI. PROPOSED SYSTEM STRUCTLIRE 



Based on the considerations discussed in previous chapters, Figure 1 is proposed as 
the structure for a sealift execution scheduling system. This structure is centered around 
three major components. The scheduler establishes the first increment of lift, given the 
cargo requirements and available ships. The rescheduler is used for all subsequent 
scheduling tasks, using all unscheduled cargo, unscheduled ships, and partially scheduled 
ships. The requirements generator is used to examine lift shortfalls and determine 
requirements for ships that can be used to make a request of Mar Ad for additional assets. 
This is a broad, high-level system specification. It lacks the detail necessary to produce 
a complete scheduling system. The point of this structure is to provide a framework upon 
which intelligent research and detailed system design can be founded. 

A. INITIAL SCHEDULER 

The initial scheduler, as proposed and shown in Figure 2, will be a first pass, single 
pass scheduler. It will be used to compute the schedule for the first increment of sealift, 
given the ships actually allocated. This is one possible place where a mathematical 
programming approach might be a viable technique, so long as some provision is made 
for allowing cargo to remain unscheduled if there are no lift assets available to move it. 
In mathematical programming this is typically accomplished by adding a dummy variable 
to the formulation. In this case, a dummy ship would have to be established and the 
formulation would need to be structured so that only cargoes without a viable lift asset 
available would be assigned to the dummy ship. Cargoes that have a good assignment 
must be protected from assignment to the dummy ship. This is not an easy formulation. 
In a such a situation, the dummy ship would have to have large capacity to allow for all . 
of the possible unscheduled cargoes, yet it would have to have a high usage cost to 
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Figure 1 Proposed System Structure 
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Figure 2 Initial Scheduler 
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prevent it from being chosen over an actual ship. This dummy ship would also have to 
be structured to allow for clear identification of the cargoes assigned to it. This would 
then be the unscheduled cargo output as shown in Figure 2. This topic has to be studied 
in much greater detail. Even with the reasonably static nature of the initial scheduler, 
a heuristic approach may still be required to meet the output and reporting requirements. 

Another stipulation that could affect the structure of the initial scheduler is the size 
<md scheduling of the first increment. For the reasons discussed in the previous chapter, 
it is more sensible to schedule ships only as they are allocated. This might preclude 
complete scheduling of the first increment in the time frame specified by the JDS 
Procedures Manual [Ref. 3] if sufficient lift assets are not identified and allocated early 
in the scheduling process. The two artificial approaches, the intelligence estimate and the 
notional ships, in truth, do not meet this requirement either because the schedules based 
on those approaches are notional, not actual. In this light, the initial scheduler should not 
be compelled to produce a completely scheduled first increment. Rather, it should take 
the assets available £uid schedule them within the 30 day window required for that 
increment. If the structure of JDS requires a complete schedule, the JDS database should 
be modified to relax this requirement, especially since any complete schedule developed 
under these conditions would be artificial at best. 

B. RESCHEDULER 

The rescheduler, for lack of a better term, will be the scheduling work horse of the 
system. As shown in Figure 1 and Figure 3, the rescheduler will be the iterative part of 
the scheduler, dealing with changes in cargoes, ships, and the increase in the scheduling 
window due to the incremental scheduling process. This is the portion of the execution 
process that will be heavily dependent upon carefully conceived and implemented heuristic 
solution techniques, such as the time-windows algorithms discussed earlier. As seen in 
Figure 3, there will be essentially four categories of input. The two cargo categories will 
be composed of cargo unscheduled in previous passes and new cargo added to the 
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Figure 3 Rescheduler 
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problem as a result of the increasing scheduling window. The two ship categories will 
be based on unused capacity from previous passes and that capacity added either by new 
ships or ships returning for subsequent assignment after performing a previous lift 
mission. The three output categories of this module will be scheduled ships/cargo, 
unscheduled cargo for consideration in another pass, and unscheduled or partially 
scheduled ships available for another pass. For the partially scheduled ships, some 
determination must be made as to whether or not its remaining capacity will be made 
available if such availability will impact the feasibility of meeting the delivery window 
of the cargoes already loaded. This is where the quality of the heuristic algorithms 
selected will be critical. If the ship loading and assignment criteria are not good, ships 
will be poorly loaded and a large amount of cargo will remain unscheduled. In an asset 
scarce and time-critical deployment this is clearly not acceptable. 

In this light, some sort of a broad, best-fit approach might be best. As a ship is up 
for assignment, the unscheduled requirements are searched for the best and most efficient 
loading, where the criteria for a best fit include the time windows, loading, and cargo 
priority considerations. This is obviously a complex question, deserving much more 
study before an effective solution can be implemented. 

C. REQUIREMENTS GENERATOR 

If, in fact, lift assets will be scarce or slow in coming, some means must be made 
available to estimate the shortfall in lift capacity under execution and characterize that 
shortfall in terms of ships required. Figure 4 shows the structure of such an estimator. 
In this case, some application of notional capacities is appropriate in that those capacities 
will only be utilized for the purpose of determining the number and type of ships that 
MarAd will be requested to provide for the execution effort. Inputs to this module will 
be the remaining unscheduled cargo and known returning ships. With respect to known 
returning ships, a decision will have to be made as to where in the return cycle a ship will 
be designated as known returning. The potential impact here is that if a ship that has 
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Figure 4 Requirements Generator 
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been so designated is attrited during the return cycle, the lift shortfall will be more severe 
than planned for. This is balanced against the recognition that the earlier an asset can be 
planned against, the more effective and timely the scheduling process. This is a 
consideration that will have to be based on the threat and probability of attrition during 
execution. 

The notional characteristics to be used for this generator can potentially come from 
several sources. There are notional ship parameters that have been incorporated as 
planning factors in the Joint Strategic Capabilities Plan (JSCP), but they were unavailable 
at this writing. JCS policy prohibits the release of planning factors to DoD schools, 
though hopefully they could be made available to a scheduling system developer. Another 
possible way to derive notional capacities would be to use some sort of a broad measure 
across several ships and ship types. Such derivation, while not desirable for actual 
scheduling, might be sufficient for developing a request for additional shipping. This 
segment is also where the nature of the external interface with MarAd comes into 
question. If a large request is to be made of MarAd, the single secure teletype might not 
be sufficient for communicating those requirements to MarAd or for MarAd’s response. 
These questions will all be contingent upon the size of the OPLAN to be executed and the 
required lift capacity. 
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vn. CONCLUSIONS AND RECOMMENDATIONS 



This analysis of sealift execution scheduling requirements is by no means complete. 
Rather, it is a broad first attempt at defining and quantifying an important and complex 
problem. As has been mentioned previously, significant work remains, particularly in the 
examination and development of an appropriate scheduling algorithm. One 
recommendation for such development is to contract for algorithmic research prior to 
contracting for an entire system. This would ensure proper development of the most 
critical component of the scheduling system. The remainder of the system could then be 
designed and developed around that scheduler. One problem with concurrent 
development of a system and a scheduler is that critical operational aspects of a scheduler 
may have to be compromised in order to make it compatible with the overall system. 
Prior development of the scheduler minimizes this problem. If the scheduler is accorded 
the requisite developmental priority and recognized software design concepts are followed, 
stressing early identification of interfaces, modularity, and complete problem definition 
prior to development, then an effective sealift execution scheduling system can be 
realized. 

Given that the development and completion of an execution scheduling system will 
probably not be a near-term reality, some interim measures to improve execution 
scheduling are in order. The first step is to improve the level of JDS support provided 
to MSC. This improvement includes training and dedicated programming support from 
USTRANSCOM. Such support has been provided in the past to MSC and the area 
commands in a sporadic and piecemeal fashion. For example, a change to the JDS 
database implemented in the fall of 1988 rendered a number of specialized database 
retrievals useless to MSCPAC. This significantly reduced scheduling efficiency and 
limited the use of a locally developed BASIC program used to sort and aggregate lift 
requirements. Second or third hand JDS support through OPNAV is not sufficient. It 
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does not seem unreasonable that USTRANSCOM should provide specialized JDS support 
to one or all of the TOAs that it is responsible for, especially since such support would 
increase overall mission capability. 

Another area where short-term improvement could be realized is in electronic data 
transfer, both internally and externally. Internally, an effort must be made to resolve the 
electronic media entry security problem with the WIN sites. It makes little sense to 
collect scheduling information online, then be required to print it out for manual entry by 
keyboard in the WIN site. This problem needs to be addressed from the standpoint of 
allowing the entry of media containing information without compromising WIN security. 
This problem cannot be ignored if a swift and effective scheduling process is to be 
developed. Externally, the initiatives for improving data communications between the 
MTMC and MSC area commands could improve the overall process. The 
communications improvements discussed in Chapter IV are not strictly tied to 
development of a specific scheduling system. Improved coordination and information 
transfer could easily be realized if such a communications interface were established. 

Sealift execution scheduling is a large, complex process, dependent upon a myriad 
of factors. While algorithmic considerations are a significant portion of the problem, all 
of the factors and processes impacting upon lift scheduling must be evaluated and 
accounted for. The ability to effectively and efficiently schedule lift is crucial to this 
nation’s strategic mobilization capability. It has to be done right. 
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GLOSSARY OF TERMS 



The definitions contained herein are drawn from NWP 80 [Ref. 1], The Joint Staff 
Officer’s Guide [Ref. 2], and the JDS Users Data Element Dictionary [Ref. 4]. Consult 
these references for other terms or further definition of the terms below. 



Available to Load Date (ALD); A date specified for each unit in the TPFDD indicating 
the earliest a cargo may begin loading at the port of embarkation. [Ref. 2] 

Cargo Category Codes (CCC): A three letter cargo identifier which provides descriptive 
information as to type, size, and transportation mode required. [Ref. 4] 

Course of Action (CO A): A possible plan open to an individual or commander that 
would accomplish or is related to the accomplishment of a mission. [Ref. 2] 

Crisis Action Procedures (CAP); See Crisis Action System. 

Crisis Action System (CAS): A system specified in JCS Pub 5-02.4 that gives guidance 
and procedures for joint operation planning by military forces during emergency or time- 
sensitive situations. The procedures are designed to give the Chairman of the Joint Chiefs 
of Staff information to develop timely recommendations to the National Command 
Authority for decisions involving the use of U.S. military forces. [Ref. 2] 

C-Day: The day on which movement from origin begins or is to begin. The deployment 
may be movement of troops, cargo, weapon systems, or a combination of these elements 
using any or all types of transportation. For planning, C-Day remains unnamed, but 
under execution, C-Day is established under the authority and direction of the Secretary 
of Defense. [Ref. 2] 

D-Day: The day on which a particular operation begins or is scheduled to begin. This 
operation may be land assault, air strike, naval bombardment, parachute assault, or 
amphibious assault. [Ref. 2] 

Elarliest Arrival Date (EAD); A day, relative to C-Day, specified by the planner as the 
earliest date a cargo can be accepted at a port of debarkation. [Ref. 2] 
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Effective U.S. Control Fleet (EUSC): U.S. citizen owned shipping registered and 
operated under a flag of convenience. 

Flag of Convenience : Merchant ship registration in countries where owner citizenship 
is not required and significant economic and operating benefits are realized through such 
registry. 

Joint Strategic Capabilities Plan (JSCP): The JSCP contains the military strategy to 
support the national security objectives and the derived military objectives. It gives 
guidance, based on projected military capabilities and conditions during the short rang 
period, and task assignments to the unified and specified Commanders in Chief and Chiefs 
of the Services for the accomplishment of military tasks. It apportions forces and lift 
assets for planning. [Ref. 2] 

Joint Chiefs of Staff (JCS): The Chairman, the Chief of Staff of the Army, the Chief 
of Naval Operations, the Chief of Staff of the Air Force, and the Commandant of the 
Marine Corps. [Ref. 2] 

Joint Deployment System (JDS): Personnel, procedures, directives, communications 
systems, and electronic data processing systems that directly support time-sensitive 
planning and execution and complement peacetime deliberate planning by disseminating 
deployment information. [Ref. 2] 

Joint Deployment Community (JDC): Those headquarters, commands, and agencies 
involved in training, preparation, movement, reception, employment, support, and 
sustainment of military forces assigned or committed to a theater of operations. The JDC 
normally consists of the JCS Joint Staff, Services, unified and specified combatant 
commands including USTRANSCOM, and defense agencies as appropriate to a given 
scenario. [Ref. 2] 

Latest Arrival Date (LAD): A day, relative to C-day, specified by the planner as the 
latest date a cargo can be accepted at a port of debarkation. [Ref 2] 

Maritime Administration (Mar Ad): The unit of the Department of Transportation 
designated to develop, promote, and maintain the U.S. merchant marine. Mar Ad is 
responsible for the RRF, NDRF, and in war as the National Shipping Authority, for 
requisitioning merchant shipping to support mobilization. [Ref. 7] 

Measurement Ton (MTon): A volumetric measure of cargo equivalent to 40 cubic feet 
of volume. [Ref. 1] 

Military Sealift Command, Atlantic (MSCLANT): The MSC area command with 
responsibility for the Atlantic area. 
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Military Sealift Command, Pacific (MSCPAC): The MSC area command with 
responsibility for the Pacific area. 

Military Airlift Command (MAC): The single management agency within the 
Department of Defense responsible for air transportation. 

Military Sealift Command (MSC): The single management agency within the 
Department of Defense responsible for ocean transportation. [Ref. 1] 

Military Traffic Management Command (MTMC): The single management agency 
within the Department of Defense responsible for management of DoD cargo movements 
within the Continental United States. [Ref. 17] 

National Command Authorities (NCA): The President and the Secretary of Defense or 
their duly deputized alternates or successors. [Ref. 2] 

National Shipping Authority (NSA): The emergency shipping operations agency 
established out of MarAd in time of war to acquire and manage merchant shipping. 
[Ref. 1] 

National Defense Reserve Fleet (NDRF): A fleet of ships acquired and maintained by 
MarAd for use in mobilization or emergency. The NDRF less the RRF is composed of 
older ships maintained at a relatively low level of readiness, available only on 
mobilization or Congressional declaration of emergency. [Ref. 1] 

Naval Control of Shipping Organization (NCSORG): The organization that in time of 
war or national emergency exercises authority for the control and direction of actual 
merchant ship movement. [Ref. 1] 

N-Day: A day prior to C-Day. N002 would reflect a day two days before C-Day. 

[Ref. 2] 

Operation Plan (OPLAN): Any plan prepared for the conduct of military operations in 
a hostile environment by the commander of a unified or specified command in response 
to a requirement established by the Chairman of the Joint Chiefs of Staff. [Ref 2] 

Operation Order (OPORD): A directive issued by a commander to subordinate 
commanders for effecting coordinated execution of an operation. [Ref. 2] 

Operational Control Authority (OCA): The naval commander respionsible for the 
control of movements and the protection of allied merchant ships within a specified 
geographical limit. [Ref 1] 
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Port of Embarkation (POE): The geographic point in the routing scheme where a 
movement requirement will begin its strategic deployment. [Ref. 2] 

Port of Debarkation (POD): The geographic point in the routing scheme where a 
movement requirement will complete its strategic deployment. [Ref. 2] 

Ready Reserve Force (RRF): A portion of the NDRF composed of ships acquired by 
MarAd with Navy funding or for the NDRF maintained in a higher state of readiness and 
available for service without mobilization or Congressional declaration of emergency. 
[Ref. 1] 

Sealift Readiness Program (SRP): A formal agreement between MSC and U.S. flag 
ocean carriers for acquisition of ships and related equipment under conditions of less than 
full mobilization. [Ref. 1] 

Sealift Strategic Planning System (SEASTRAT): MSC’s newest deliberate planning 
system for sealift. SEASTRAT is programmed as a replacement for SEACOP. 

Strategic Algorithm for Improving Lift (SAIL): SAIL is the sealift scheduling module 
contained within SEASTRAT. 

Strategic Sealift Contingency Planning System (SEACOP): MSC’s 1970 era deliberate 
planning system for sealift. 

Supported Command/Commander; The commander who originates operation plans in 
response to requirements of the Chairman of the Joint Chiefs of Staff. In an employment 
scenario, the supported commander will be the commander tasked with executing a given 
course of action. [Ref. 2] 

Supporting Command/Commander: A commander who furnishes augmentation forces 
or other support to a supported commander. [Ref. 2] 

Time Phased Force Deployment Data (TPFDD): The computer- supported portion of an 
OPLAN that contains time-phased force data, non-unit-related cargo, and personnel data, 
and movement data for the OPLAN. Information includes in-place units, prioritized 
arrival of units deployed to support the OPLAN, etc. [Ref. 2] 

Transportation Operating Agencies (TOA): Military Traffic Management Command 
(MTMC), Military Sealift Command (MSC), and Military Airlift Command (MAC). 

Type Unit Data File (TUCHA): A files that gives standard planning data and movement 
characteristics for personnel, cargo, and accompanying supplies associated with 
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deployable type units of fixed composition. The file contains the weight and volume of 
selected cargo categories, physical characteristics of the cargo, and the number of 
personnel requiring non-organic transportation. (A person assigned to a destroyer would 
be considered to have organic transportation.) [Ref, 2] 

U.S. Transportation Command (USTRANSCOM): The unified combatant command 
for transportation missions, responsibilities, and the forces of MTMC, MSC, and MAC, 
[Ref. 18] 

Voluntary Tanker Agreement (VTA): Procedures for voluntary contribution of tanker 
capacity by commercial tanker owners and operators administer^ by MarAd, [Ref, 1] 

World Wide Military Command and Control System (WWMCCS): The system that 
provides the means for operational direction and technical administrative support involved 
in the function of command and control of U.S. military forces. [Ref. 2] 

WWMCCS Intercomputer Network (WIN): The system that provides for remote access 
and data transfer between users within WWMCCS. [Ref. 2] 
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